1. Field of the Invention
The invention relates to storage management and more specifically relates to protocols associated with reservation of portions of a storage subsystem multi-initiator or clustered host environment.
2. Discussion of Related Art
Numerous computing applications utilize high performance and high reliability storage subsystems. Such subsystems are used for storing significant volumes of user and system data. Such storage may require high performance where processing transaction rates or raw data transfer rates required for particular applications are substantial. High reliability is often required in mission critical computing applications where loss of data or even temporary unavailability of stored data is unacceptable for the particular application.
Often such high performance and high reliability storage systems utilize SCSI command structures. SCSI commands are standardized in accordance with specifications widely accepted in the industry. Numerous broad revisions of the SCSI command standard specifications have evolved over the years. In particular, SCSI2 has evolved as a widely accepted standard but has given way to equally broad acceptance of SCSI3 standards in recent years.
One particular feature provided in the SCSI2 standards relate to so-called reservation protocols. Reservation protocols generally allow for and an attached host system to request exclusive access to portions of a SCSI2 storage subsystem. The portion to be reserved may comprise the entirety of a volume or logical unit within the storage subsystem or may comprise smaller extents or portions of a volume or logical unit. In general, a host system (often referred to as an initiator) transmits a reservation request to the storage subsystem (often referred to as a target). In response to receipt of such a reservation request, the storage subsystem reserves the requested portion of the storage subsystem for exclusive accessed by the requesting initiator. When the requested and granted exclusive access is no longer required by the host system, it transmits a release request to the storage subsystem to release its temporary exclusive access to the previously reserved portion of the subsystem.
A problem arises in use of the SCSI2 reservation protocols in that if an initiator (i.e., a host system) abnormally ends operation having a portion of the storage system reserved, the reserved portion may be inaccessible to other host systems coupled to the storage subsystem. A partial solution to this problem as presently practiced in the art involves performing a reset of the storage subsystem to release all previously reserved portions of the storage subsystem. Each host system coupled to the reset storage subsystem must then reestablish any required a reservations for its ongoing exclusive access to the storage subsystem.
SCSI3 command standard specifications provide a different architecture for reservation protocols. Under the SCSI3 command standard specifications, a persistent reservation may be established by a request from a host the system directed to the storage subsystem (i.e., a persistent reservation out command). Any host system coupled to the SCSI3 storage subsystem may also inquire of the storage subsystem as to presently established persistent reservations. A persistent reservation in SCSI3 command returns information from the storage subsystem to the requesting host system to thereby discover all presently active reservations. Unique identifiers are associated with each such presently active reservation. A so called “third party” release parameter is available in the persistent reservation out SCSI3 command to allow any initiator (any host) to force the release of a previously requested persistent reservation on behalf of an abnormally terminated host system application.
Further details of both SCSI2 and SCSI3 reservation protocols are generally known in the art and maybe viewed in public specification standards such as available on the Web at www.t10.org. In particular, SCSI3 persistent reservation commands and exchange protocols are discussed in: SPC-3 SCSI Primary Commands-3 (third generation command set for all SCSI devices), which is hereby incorporated by reference. The older SCSI2 reservation protocols are now obsoleted by the updated SCSI3 persistent reservation protocols. However, since older legacy systems still generate such sequences, the specifications therefor are still available such as in SPC SCSI-3 Primary Commands (first generation command set for all SCSI devices) which is hereby incorporated by reference. In view of these differences, reservations are typically managed differently by host systems designed for SCSI2 storage subsystems as compared to host systems adapted for interaction with SCSI3 storage subsystems.
A problem arises where a new storage subsystem supporting SCSI3 reservation protocols is coupled to one or more host systems that provide support only for SCSI2 reservation protocols. It is problematic to require such an older (“legacy”) host system to convert its operating system and/or and applications from SCSI2 reservation protocols to SCSI3 reservation protocols. It is therefore evident that a need exists for improved methods and structures to permit effective reservation management for SCSI2 based legacy host applications coupled to SCSI3 storage subsystems.